Release 10.1A: OpenEdge Data Management:
DataServer for Microsoft SQL Server

Forward and backward scrolling

A query is scrolling if you specify SCROLLING in the DEFINE QUERY statement or if you define a browse for the query. You can use the REPOSITION statement to change your current position with the result set. For a non-scrolling query, the DataServer allows you to only move sequentially forward through the rows by using the FIRST and options of the GET statement. Scrolling basically means that the result set is cached on the client for backward and forward scrolling.

With the DataServer, forward and backward scrolling works with an MS SQL Server just as it does with an OpenEdge database except when the data source fails to find a record. In the 4GL, the cursor position can change after a failed search; however, with the DataServer, a failed search does not affect the cursor. For example, if a cursor is positioned at cust-num 50 and a request for the next customer from an OpenEdge table fails, the cursor moves to the next sequential record beyond cust-num 50. The same failed request from a data source leaves the cursor at cust-num 50. Your DataServer applications should not assume a certain cursor position after a failed find.

You can, however, still use the AVAILABLE function to determine whether a record is available. The AVAILABLE function behaves consistently whether it accesses an OpenEdge database or an MSS data source.

Impact of MAX-ROWS

The MAX-ROWS qualifier on a query determines the number of rows returned. The MAX-ROWS calculation is applied before any sorting is applied to the query, causing the results to be random. Consider the following example:

DEFINE QUERY x FOR cust SCROLLING. OPEN QUERY x FOR EACH cust MAX-R0WS 15. GET LAST x. DISPLAY cust.cust-num. REPEAT: GET PREV x. DISPLAY cust.cust-num. END.

When this example is run with the OpenEdge sports database, the first record return has cust-num 54, and the repeat loop displays other cust-nums in descending order from there. When this example is run with the sports database migrated to SQL Server, the first record returned has cust-num 15, and the repeat loop displays values in descending order from there. This difference in results is a caused by the MAX-ROWS being applied prior to the sorting.